Would be interested to hear if @kshitijrajsharma is ok with osm_data_client, but personally I think it's not descriptive for what the package is.
Sure it gets OSM data, but it's specifically from the osm-rawdata database that HOT hosts, not directly from OSM.
I named it raw-data-api-py to indicate it's the Python client for raw-data-api 😄

But then again, osm_data_client is a bit more user friendly, soooo

Perhaps raw-data-api would be better named with osm in there somewhere for clarity too

Actually something I forgot to mention in the requirements is the possibility of uploading a YAML config via the /custom/snapshot endpoint 😅

hotosm/field-tm#1456

Example of supported YAMLs: https://github.com/hotosm/osm-fieldwork/tree/main/osm_fieldwork/data_models

Previously we were parsing the YAML --> JSON format for sending to raw-data-api in a package osm-rawdata.

What I think we should do:

• Allow passing through YAML files directly to raw-data-api custom snapshot endpoint (don't parse it in advance, as raw-data-api should be able to handle this).
• Eventually either deprecate osm-rawdata (although I think Rob still wanted stuff in there), or just replace the remote query code in their with code from this package (not a priority at all).

Not that picky with the naming , I am assuming you might need rafactor but usually the descriptive naming of the tool I find it more useful , raw-data-api-py would be descriptive

Will review and merge this asap - just back from holidays 👍

Actually I just realised that's not the package name, but just the import name.

I'm happy with raw-data-api-py being the published package, but importing in code as osm_data_client 👍

I'll publish it now 😄